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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Introduction 

The present document is part of a TS-family covering the 3^^ Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

TS 32.150: Integration Reference Point (IRP) Concept and definitions 

TS 32.151: Integration Reference Point (IRP) Information Service (IS) template 

TS 32.152: Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language 

(UML) repertoire 

TS 32.153 Integration Reference Point (IRP) technology specific templates 

TS 32.154 Backward and Forward Compatibility (BFC); Concept and definitions 

TS 32.155 Telecommunication management; Requirements template 
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Scope 



The present document provides the overall concept for all Integration Reference Point (IRP) specifications. 
Relevant IRP overview and high-level definitions are already provided in 3GPP TS 32.101 [1] and TS 32.102 [2]. 

IRP specifications are intended to be applicable to any management interface (see definition of Integration Reference 
Point in subclause 3.1). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.151: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) template". 

[4] 3GPP TS 32.152: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) Unified Modelling Language (UML) repertoire". 

[5] ITU-T Recommendation M.3020: "TMN Interface Specification Methodology" . 

[6] OMG IDL Style Guide, ab/98-06-03, June 17, 1998. 

[7] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point: Information Service (IS)". 

[8] 3GPP TS 32.601: "Telecommunication management; Configuration Management (CM); Basic CM 

Integration Reference Point (IRP); Requirements". 

[9] 3GPP TS 32.602: "Telecommunication management; Configuration Management (CM); Basic CM 

Integration Reference Point (IRP): Information Service (IS)". 

[10] 3GPP TS 32.603: "Telecommunication management; Configuration Management (CM); Basic CM 

Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) 
Solution Set (SS)". 

[II] 3GPP TS 32.621: "Telecommunication management; Configuration Management (CM); Generic 
network resources Integration Reference Point (IRP); Requirements". 

[12] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[13] 3GPP TS 32.623: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Common Object Request Broker 
Architecture (CORBA) Solution Set (SS)". 

[14] 3GPP TS 32.671: "Telecommunication management; Configuration Management (CM); State 

Management Integration Reference Point (IRP): Requirements". 
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[15] 3GPP TS 32.672: "Telecommunication management; Configuration Management (CM); State 

Management Integration Reference Point (IRP): Information Service (IS)". 

[16] 3GPP TS 32.673: "Telecommunication management; Configuration Management (CM); State 

Management Integration Reference Point (IRP): Common Object Request Broker Architecture 
(CORE A) Solution Set (SS)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.151 [3] and the following apply: 

Data Definition IRP: 3GPP publishes IRP specifications relating to commonly used data definitions that can be 
imported for use by Interface IRP and/or NRM IRP. This term represents all such specifications. An example of a Data 
Definition IRP is the State Management IRP (32.671 [14], 32.672 [15], 32.673 [16], etc). 

Information Object Class (IOC): Describes the information that can be passed/used in management interfaces and is 
modelled using the stereotype "Class" in the UML meta-model. For a formal definition of Information Object Class and 
its structure of specification, see 3GPP TS 32. 151 [3]. 

Integration Reference Point (IRP): An architectural concept that is described by a set of specifications for definition 
of a certain aspect of a management interface, comprising a Requirements specification, an Information Service 
specification, and one or more Solution Set specifications. 

Interface IRP: 3GPP publishes a number of IRP specifications each of which is related to a set of operations and 
notifications for a specific telecom management domain such as alarm management, configuration management, etc. 
Interface IRPs also contain definitions of Support lOCs. This term represents all such specifications. An example of an 
Interface IRP is the Basic CM IRP (the set of TSs 32.601 [8], 32.602 [9], 32.603 [10], etc.). 

IRPAgent: Encapsulates a well-defined subset of network (element) functions. It interacts with IRPManagers using one 
or more IRPs. From the IRPManager's perspective, the IRPAgent behaviour is only visible via the IRP(s). 

Information Service (IS): an IRP Information Service describes the information related to the entities (either network 
resources or support objects) to be managed and the way that the information may be managed for a certain functional 
area (e.g. the Alarm IRP Information Service in the fault management area). Information Services are defined for all 
IRPs. 

IRPManager: Models a user of IRPAgent(s) and it interacts directly with the IRPAgent(s) using IRP(s). 

Since the IRPManager represents an IRPAgent user, it gives a clear picture of what the IRPAgent is supposed to do. 

From the IRPAgent perspective, the IRPManager behaviour is only visible via the IRP. 

Solution Set (SS): contains a mapping of the IRP Information Service (IS) to one of several technologies. An IS can be 
mapped to several different Solution Sets. Different technology selections may be made for different IRP Information 
Services. The functionality and information specified in a Solution Set is constrained by the functionality and 
information specified in the associated Information Service. 

Managed Object: Entity used to represent information in a Solution Set. The Managed Objects (MO) are obtained as 
the result of a mapping exercise of Information Objects defined in IS, taking into account some engineering choices and 
technology specificity. 

Network Resource Model (NRM): An Information Service describing Information Object Classes representing the 
manageable aspects of network resources, e.g. an RNC or NodeB. 

NRM IRP: 3GPP publishes a number of IRP specifications each of which is related to a particular NRM (Network 
Resource Model) as defined in 3GPP TS 32.101 [1]. NRM IRPs do not define any operations or notifications. This term 
represents all such specifications. Note: In some NRM IRP titles, for historic reasons, they are named "...network 
resources IRP"). An example of an NRM IRP is the Generic NRM IRP (32.621 [11], 32.622 [12], 32.623 [13], etc.). 
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Support IOC: IOC that represents a particular capability, introduced to model a management service. As an example of 
Support IOC, in the Alarm IRP Information Service [59] there are the Alarmlnformation and AlarmList lOCs. 

YyyIRP: 3GPP defines a number of support-IOCs (defined in Interface IRPs) such as AlarmlRP, BasicCMIRP and 
EPIRP. This term represents all such support-IOCs. 

Yyy IRP: For a specific Interface IRP such as the Basic CM IRP, when the letters Yyy are replaced by the specific key 
words naming that IRP (in the given example the Yyy is replaced by 'Basic CM'), this term represents all specifications 
that are part of that Interface IRP. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.151 [3] and the following apply: 

CORBA Common Object Request Broker Architecture 

EM Element Manager 

GDMO Guidelines for the Definition of Managed Objects 

GUI Graphical User Interface 

IDL Interface Definition Language 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

NE Network Element 

NM Network Manager 

NRM Network Resource Model 

OMG Object Management Group 

ORB Object Request Broker 

PSA Product Specific Application 

SMP System Management Processes 

SNM Sub-Network Manager 

SS Solution Set 

TMF TeleManagement Forum 

TOM Telecom Operations Map 

UML Unified Modelling Language 
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Integration Reference Points (IRPs) 



4.1 



Introduction 



For the purpose of management interface development 3 GPP has developed an interface concept known as Integration 
Reference Point (IRP) to promote the wider adoption of standardized management interfaces in telecommunication 
networks. The IRP concept and associated methodology employs protocol and technology neutral modelling methods as 
well as protocol specific solution sets to achieve its goals. 

4.1.1 General 

The three cornerstones of the IRP concept are: 

- Top-down, process-driven modelling approach: The purpose of each IRP is automation of one specific task, 
related to TMF TOM. This allows taking a "one step at a time" approach with a focus on the most important 
tasks. 

- Technology-independent modelling: To create from the requirements an interface technology independent 
model. This is specified in the IRP Information Service. 

- Standards-based technology-dependent modelling: To create one or more interface technology dependent 
models from the technology independent model. This is specified in the IRP Solution Set(s). 



IRP REQUIREMENTS 



IRP INFORMATION SERVICE 

+ 




y 



IRP SOLUTION SETS 



^ns^ 



Figure 4.1 : IRP components (with example Solution Sets; for definition of valid 3GPP Solution Sets, 

see Annex C in TS 32.101 [1]) 
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4.1 .2 IRP Specifications Approach 



As highlighted in the previous subclause, IRP specifications are specified using a 3-level approach: Requirements, IS- 
level and SS -level. 

Furthermore, there are three categories of IRP specifications (see formal and more detailed definitions in subclause 3.1): 

• Interface IRPs 

• NRM IRPs 

• Data Definition IRPs. 

Each category is partitioned into Requirements, IS-level and SS-level specifications. 



Requirements/ Use Cases 



Interface IRP's 



NRM IRP's 



Data 
Definition IRP's 



Information Service Definitions (UIVIL) 



• Notification IRP 


• Generic NRM 


• Alarm IRP 


• CoreNWNRM 


• BulkCM IRP 


• UMTS NRM's 


• KernelCM IRP 


• CDMA NRM's 


• BasicCM IRP 


• Inventory NRM 


• etc 


• etc 



• state MgmtIRP 

• etc 



/rKL Relative stable 

(J^_/ over long 

^i period of time 



^p4. - Changes only with 
{ ^ I respect to addition 
^^/ and extensions 



Solution Set Definitions (CORBA, SOAP, XML, CMIP) 
Solution Set Definitions (other/future e.g. JAVA , SNMP) 



/gyi , Changes with 
^ ^ / new/better 

^»/ Technologies 



Figure 4.2: The IRP 3-Level Specifications Approach combined with the three IRP categories. 

Level 1: 

The "Requirements-level" intends to provide conceptual and use cases definitions for a specific management 
interface aspect as well as defining subsequent requirements for this IRP. 



Level 2: 



The "IS-level" provides the technology independent specification of an IRP. 



Level 3: 



The "SS-level" finally provides the mapping of IS definitions into one or more technology-specific Solution 
Sets. This concept provides support for multiple interface technologies as applicable on a vendor and/or network 
type basis and also enables accommodation of future interface technologies - without the need to redefine 
requirements and IS-level definitions. 
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4.2 Integration levels 



Virtually all types of telecom/datacom networks comprise many different technologies purchased from several different 
vendors. This implies that the corresponding management solution need to be built by integrating product- specific 
applications from different vendors with a number of generic applications that each provide some aspect of 
multi-vendor and/or multi-technology support. A complete management solution is thus composed of several 
independent applications. 

The following levels of integration are defined: 

- Screen Integration: Each application provides its own specific Graphical User Interface (GUI) that need to be 
accessible from a single, unified screen (a common desktop). A seamless integration between the various GUIs 
is then required. Screen Integration is not specified in the present document. 

- Application Integration: Applications need to interwork, on a machine-machine basis, in order to automate 
various end-to-end processes of a communication provider. 

4.2.1 Application integration 

Interfaces related to application integration can be divided in the following three categories: 

1) High-level generic interfaces: between generic applications on the network and service management layers. 
The same approach and concepts apply for these as the next category. 

2) High-level (technology-independent to the extent possible) interfaces: between product- specific and generic 
applications are needed in order to automate and streamline frequently occurring tasks applicable to several types 
of network elements. A top-down approach shall be taken when defining these interfaces, where the main input 
is: 

a) business processes of a communication provider; and 

b) the types of generic applications that are used to implement the process support. 

3) Detailed (product-specific) interfaces: between product- specific applications and the corresponding network 
elements are of course also needed. These interfaces are defined using the traditional bottom-up approach, where 
the actual network infrastructure is modelled. This is the traditional TMN approach to element management. The 
management information in these interfaces is not further discussed in the present document, as it is internal to a 
specific development organization and does not need to be open. In fact, by publishing the management 
information in these interfaces, too much of the internal design may be revealed and it may become impossible 
to later enhance the systems that are using the interfaces. The management services (operations and 
notifications) and protocol shall however be open and standardized as long as they are independent of the NRM 
describing the managed NEs/NRs. 
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4.3 Application of IRPs 



When providing integrated management solutions for multi- vendor networks, there is a strong requirement that the NEs 
and the management solutions that go together with them are systems integratable. 

It should be noted that these IRPs could be provided by an IRP Agent on any management interface. 

These IRPs are introduced to ensure interoperability, for example between Product- Specific Applications (PSA) and the 
Network and System Management Processes (SMP) of the Network Manager (NM) - see figure 4.3 from TS 32.101 [1]. 
These IRPs are considered to cover the most basic needs of task automation. 



IRP (alternative 1) 



IRP (alternative 2) 




■ Network Manager ■ 



Network & System Management Processes 



Network 

Planning & 

Development 



Network 

Inventory 

Management 



Network 
Provisioning 



Network 
Maintenance 
& Restoration 



Network Data 
Management 



■\ f 



Service CM IRPs Common IRPs ^m ippg 

IRPs (Bulk, Inventory, (Notification, File (Alarm Test ) 

State....) Xfer, Log...) 




PSA = Product Specific Application 
NE = Network Element 



Figure 4.3: Examples of IRPs for application integration 

Taking one of the above mentioned IRPs as an example, the Network and System Management Processes have similar 
need to receive notifications from various PSAs. The corresponding service is formalized as a Notification IRP. 
It specifies: firstly, an interface through which subscriptions to different types of notifications can be set-up 
(or cancelled), and secondly, common attributes for all notifications. 

Further, applying a common Name Convention for Managed Objects is useful for co-operating applications that require 
identical interpretation of names assigned to network resources under management. 
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4.4 Defining the IRPs 



It is important to accommodate more than one specific technology, as the technologies will change over time. 
Applications need to be future-proof. One fundamental principle for achieving this is to clearly separate the semantics 
of information definition from the protocols definitions (accessing the information) for the external interfaces. 

The framework being used to define IRPs allows the implementation of user requirements for each management 
capability (e.g. configuration management), by modelling the information related to the resources to be managed and 
the way that the information may be accessed and manipulated. Such modelling is done in a way that is independent of 
the technology and distribution used in the implementation of a management system. 

The IRP methodology uses the following steps: 

a) Capture the management requirements. 

b) Specify the semantics of the information to describe the system. Trace back to item (a). 

c) Specify the semantics of the interactions between the management system and its clients. Trace back to item (a). 

d) Specify the syntaxes of the information and interactions identified in (b) and (c). The specification is technology 
dependent. Trace back to items (b) and (c). 

Figure 4.4 shows an example of how an IRP can be structured (the Alarm IRP). 



Alarm IRP: Requirements 



Alarm IRP: Information Service 



Notifications for Alarm reporting and operations possible over the Alarm IRP (Specified in 
UML and natural language). 



SNMP Solution Set 



Alarm IRP mapped to 
SNMP including standard 
SNMPMIB:s 



CORBA Solution Set 



Alarm IRP mapped to 
CORBA IDL files. Alarm 
reporting mapped to OMG 
Structured events. 



CMIP Solution Set 



Alarm IRP mapped to 
GDMO including relevant 
ITU-T standards. 



Requirements 



Information Service 




Solution Set 
Layer 




CORBA/IIOP 



CMIS 



CMIP 



Application 
Layer 



UDP 



TCP 



OSI transport protocol 



Transport 
Layer 



IP 



OSI network protocol 



Network 
Layer 



Figure 4.4: Example of an IRP (Alarm IRP) 



4.5 



Void 



ETSI 



3GPPTS 32.150 version 9.1.0 Release 9 13 ETSI TS 132 150 V9.1. 0(201 0-04) 

4.6 Mandatory, Optional and Conditional qualifiers 

This subclause defines a number of terms used to qualify the relationship between the Information Service, the Solution 
Sets and their impact on the IRP implementations. The qualifiers defined in this clause are used to qualify IRP Agent 
behaviour only. This is considered sufficient for the specification of the IRPs. 

IS specifications define IOC attributes, interfaces, operations, notifications, operation parameters and notification 
parameters. They can have the following support/read/write qualifiers: M, O, CM, CO, C. 

Definition of qualifier M (Mandatory): 

• Used for items that shall be supported. 

Definition of qualifier O (Optional): 

• Used for items which may or may not be supported. 

Definition of qualifier CM (Conditional-Mandatory): 

• Used for items that are mandatory under certain conditions, specifically: 

o All items having the support qualifier CM shall have a corresponding constraint defined in the IS 
specification. If the specified constraint is met then the items shall be supported. 

Definition of qualifier CO (Conditional-Optional): 

• Used for items that are optional under certain conditions, specifically: 

o All items having the support qualifier CO shall have a corresponding constraint defined in the IS 
specification. If the specified constraint is met then the items may be supported. 

Definition of qualifier C (SS-Conditional): 

• Used for items that are only applicable for certain but not all Solutions Sets (SSs). 

SS specifications define the SS -equivalents of the IS-defined IOC attributes, operations, notifications, operation 
parameters and notification parameters. These SS -equivalents can have the following support/read/write qualifiers: M, 
O, CM and CO. 

The mapping of the qualifiers of IS-defined constructs to the qualifiers of the corresponding SS-constructs is defined as 
follows: 

• For qualifier M, O, CM and CO, each IS-defined item (operation and notification, input and output parameter of 
operations, input parameter of notifications, information relationship and information attribute) shall be mapped 
to its equivalent(s) in all SSs. Mapped equivalent(s) shall have the same qualifier as the IS-defined qualifier. 

• For qualifier C, each IS-defined item shall be mapped to its equivalent(s) in at least one SS. Mapped 
equivalent(s) can have support qualifier M or O. 
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Table 4.6 defines the semantics of qualifiers of the Interface IRP SS equivalents, in terms of support from the IRP Agent perspective. 



Table 4.6: Semantics for Mandatory, Optional and Conditional qualifiers used in Solution Sets 



Mapped 88 
Equivalent 


Mandatory 


Optional 


Conditional-Mandatory 

(CM) 


Conditional-Optional (CO) 


Mapped 

notification 

equivalent 


The IRPAgent 
shall generate the 
notification. 


The IRPAgent may or may not generate it. 


The IRPAgent shall generate 
this notification if the 
constraint described in the IS 
for this item is satisfied. 


The IRPAgent may choose whether 
or not to generate it. If the 
IRPAgent chooses to generate it, the 
constraint described in the IS for this 
notification must be satisfied. 


Mapped 

operation 

equivalent 


The IRPAgent 
shall support it. 


The IRPAgent may or may not support this operation. If the 
IRPAgent does not support this operation, the IRPAgent shall 
reject the operation invocation with a reason indicating that the 
IRPAgent does not support this operation. The rejection, together 
with a reason, shall be returned to the IRPManager. 


The IRPAgent shall support 
this operation if the constraint 
described in the IS for this 
item is satisfied. 


The IRPAgent may support this 
operation if the constraint described 
in the IS for this item is satisfied. 


Input parameter 
of the mapped 
operation 
equivalent 


The IRPAgent 
shall accept and 
behave according 
to its value. 


The IRPAgent may or may not support this input parameter. If the 
IRPAgent does not support this input parameter and if it carries 
meaning (i.e. it does not carry no-information semantics), the 
IRPAgent shall reject the invocation with a reason (that it does not 
support the parameter). The rejection, together with the reason, 
shall be returned to the IRPManager. 


The IRPAgent shall accept 
and behave according to its 
value if the constraint 
described in the IS for this 
item is satisfied. 


The IRPAgent may accept and 
behave according to its value if the 
constraint described in the IS for this 
item is satisfied. 


Input parameter 

of mapped 

notification 

equivalent 

AND 

output parameter 

of mapped 

operation 

equivalent 


The IRPAgent 
shall supply this 
parameter. 


The IRPAgent may supply this parameter. 


The IRPAgent shall supply 
this parameter if the 
constraint described in the IS 
for this item is satisfied. 


The IRPAgent may supply this 
parameter if the constraint described 
in the IS for this item is satisfied. 


Mapped IOC 

attribute 

equivalent 


The IRPAgent 
shall support it. 


The IRPAgent may support it. 


The IRPAgent shall support 
this attribute if the constraint 
described in the IS for this 
item is satisfied. 


The IRPAgent may support this 
attribute if the constraint described in 
the IS for this item is satisfied. 
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4.7 System context for Interface IRPs 

Every Interface IRP on a management interface (e.g. Alarm IRP, Notification IRP, Basic CM IRP, Bulk CM IRP) is 
subject to a System Context as described in this subclause (also consistent with 3GPP TS 32.102 [2] clause 8). 

Figure 4.7.1 and 4.7.2 identify system contexts of the Interface IRP in terms of its implementation, called IRP Agent, 
and the user of the IRP Agent, called IRPManager. 

Each IRP Agent implements and supports one or more IRPs. The set of IRPs that is related to each Interface IRP is 
defined by the System Context subclause in each individual Interface IRP IS specification, e.g. subclause 4.2 in the 
Alarm IRP IS [7]. 

An NE can be managed via System Context A or B. The criterion for choosing System Context A or B to manage a 
particular NE is implementation dependent. An IRP Agent shall support one of the two System Contexts. By observing 
the interaction across the management interface, an IRPManager cannot deduce if the EM and NE are integrated in a 
single system or if they run in separate systems. 



IRPManager 



NM 



IRPAgent 




NEs 



management 
interface (e.g. Itf-N) 



EM 



Supported IRP(s) 



Figure 4.7.1 : System Context A 
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Figure 4.7.2: System Context B 
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Annex A (informative): 
Void 
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Annex B (normative): 
Void 
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Annex C (informative): 
Void 
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Annex D (informative): 
Void 
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Annex E (normative): 
Void 



ETSI 



3GPPTS 32.150 version 9.1.0 Release 9 21 ETSI TS 132 150 V9.1. 0(201 0-04) 



Annex F (informative): 
Void 
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Annex G (normative): 

IOC Properties, Inheritance and Import 

G.1 Property 

The properties of an IOC (including Support IOC) are specified in terms of the following: 

a) An IOC attribute(s) including its semantics and syntax, its legal value ranges and support qualifications. The 
IOC attributes are not restricted to Configuration Management but also include those related to, for example, 
1) Performance Management (i.e., measurement types), 2) Trace Management and 3) Accounting 
Management. 

b) The non-attribute-specific behaviour associated with an IOC (see Note 1). 

NOTE 1: As an example, the Link between MscServerFunction and CsMgwFunction is optional. It is mandatory if 
the MscServerFunction instance belongs to one ManagedElement instance while the CsMgwFunction 
instance belongs to another ManagedElement instance. This Link behaviour is a non-attribute-specific 
behaviour. It is expected that this behaviour, like others, will be inherited. 

c) An IOC relationship(s) with another lOC(s). 

d) An IOC notification type(s) and their qualifications. 

e) An IOC's relation with its parents (see Note 2). There are three mutually exclusive cases: 

1) The IOC can have any parent. In UML diagram, the class has a parent Any. 

2) The IOC is abstract and all of the possible parent(s) have been designated and whether subclass lOCs can 
be designated as a root IOC. In UML diagram, the class has zero or more possible parents of specific 

classes (except Any) . 

3) The IOC is concrete and all of the possible parent(s) have been designated and whether the IOC can be 
designated as a root IOC. In UML diagram, the class has one or more possible parents of specific classes 
(except Any . ) 

An IOC instance is either a root IOC or it has one and only one parent. Only 3 GPP SA5 may designate an IOC 
class as a potential root IOC. Currently, only SubNetwork, ManagedElement or MeContext lOCs can be root 
IOCS. 

NOTE 2: The parent and child relation in this clause is the parent name-containing the child relation. 

f) An IOC's relation with its children. There are three mutually exclusive cases: 

1) An IOC shall not have any children (name-containment relation) lOCs. In UML diagram, the class has no 
child. 

2) An IOC can have children lOC(s). The maximum number of instances per children IOC can be specified. 
An IOC may designate that vendor specific objects are not allowed as children lOCs. In UML diagram, 
the class has a child Any . 

3) An IOC can only have the specific children lOC(s) (or their subclasses). The maximum number of 
instances per children IOC can be specified. An IOC may designate that vendor specific objects are not 
allowed as children lOCs. In UML diagram, the class has one or more children of specific classes (except 

Any) . 

g) Whether An IOC can be instantiated or not (i.e., whether An IOC is an abstract IOC). 
h) An attribute for naming purpose. 
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i) An optional attribute for holding IOC name. An IOC name is unique among all 3GPP-defined lOCs and 
vendor-defined lOCs. An IOC name must be unambiguous. 

Editor's Note: No agreement on above point i) achieved yet. This is FFS.] 



G.2 Inheritance 

An IOC (the subclass) inherits from another IOC (the superclass) in that the subclass shall have all the properties of the 
superclass. 

The subclass can change the inherited support-qualification(s) from optional to mandatory but not vice versa. The 
subclass can change the inherited support-qualification from conditional -optional to conditional-mandatory but not vice 
versa. 

An IOC can be a superclass of many lOC(s). A subclass cannot have more than one superclass. 

The subclass can: 

a) Add (compared to those of its superclass) unique attributes including their behaviour, legal value ranges and 
support-qualifications. Each additional attribute shall have its own unique attribute name (among all added 
and inherited attributes). 

b) Add non-attribute behaviour on an IOC basis. This behaviour may not contradict inherited superclass 
behaviour. 

c) Add relationship(s) with lOC(s). Each additional relationship shall have its own unique name (among all 
added and inherited relations). 

d) Add additional notification types and their qualifications. 

e) Designate all of the possible parent(s) (and their subclasses) if the superclass has Property-e-1 such that an IOC 
will have Property-e-2 or Property-e-3. Restrict possible parent(s) (and their subclasses) and/or remove the 
capability of the subclass from being a root IOC, if the superclass has Property-e-2 or Property-e-3. 

f) Add children lOC(s) if the superclass has Property-f-2 such that an IOC will have Property-f-3. Restrict the 
allowed children lOC(s) (or their subclasses) if the superclass has Property-f-3. 

g) Specify whether an IOC can be instantiated or not (i.e. the IOC is an abstract IOC). 
h) Restrict the legal value range of a superclass attribute that has a legal value range. 



G.3 Import 



NRM IRP specifications define lOCs. To facilitate re-use of NRM IOC definitions among IRP specifications, an 
import mechanism is used by one NRM IRP (called the subject NRM IRP) specification to reuse IOC definition defined 
in another NRM IRP specification. When the subject NRM IRP specification imports an IOC, it cannot change the 
imported IOC property. If it requires changes to the imported IOC, it must use inheritance to define its own new class. 
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